The ROme OpTimistic Simulator: core internals and programming model

In this article we overview the ROme OpTimistic Simulator (ROOT-Sim), an open source C/MPI-based simulation package targeted at POSIX systems, which implements general-purpose parallel/distributed simulation environment relying on the optimistic (i.e. rollback based) synchronization paradigm. It offers a very simple programming model based on the classical notion of simulation-event handlers, to be implemented according to the ANSI-C standard, and transparently supports all the services required to parallelize the execution. It also offers a set of optimized protocols (e.g. CPU scheduling and state log/restore protocols) aimed at minimizing the run-time overhead by the platform, thus allowing for high performance and scalability. Here we overview the core internal mechanisms provided within ROOT-Sim, together with the offered API and the programming model that is expected to be agreed in order to produce simulation software that can be transparently run, in a concurrent fashion, on top of the ROOT-Sim layer. Short code examples are also discussed. 1. ROOT-SIM ARCHITECTURE The internal architecture of ROOT-Sim can be schematized as in Figure 1. It is composed of a set of interacting sub-systems, which ultimately rely on standard C libraries and the MPI layer. At the core of the architecture, there is an event-queue manager that maintains multiple input/output queues storing incoming (or already processed) and outgoing simulation events. Each pair of input/output queues is logically associated with a same locally hosted simulation object. The interaction between the event-queue manager and the MPI layer, in order to support event notification across different instances of the ROOT-Sim kernel, is mediated by a messaging manager which multiplexes ROOTSim defined message tags (e.g. EVENT vs ANTI_EVENT notifications) possibly travelling across different ROOT-Sim instances over the same MPI communicator, in order to exploit the associated FIFO property. The current state of the input event queues is exposed to the scheduling sub-system, which gives control to the application layer along the same thread running the scheduler. Hence, simulation events (and the associated simu∗http://www.dis.uniroma1.it/ ̃quaglia/software/ROOT-